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Executive  Summary 


This  document  discusses  the  current  status  of  the  Engineering  Information  Systems  (EIS) 
program,  which  recently  underwent  a  final  review  of  the  prototype  design  specifications.  The 
document  concludes  that  the  EIS  design  specifications  comply  with  a  majority  of  the  original  IDA 
developed  EIS  requirements;  however,  additional  careful  planning  and  risk  analysis  are  needed. 
The  program  is  entering  the  prototype  demonstration  phase,  and  given  the  maturity  of  selected 
technology  areas,  some  of  the  desired  functionality  is  not  yet  in  place.  Additional  functionality  that 
would  provide  incentive  for  adoption  and  use  is  needed,  and  some  of  this  functionality  depends  on 
research-level  results. 

The  effectiveness  of  the  EIS  program  would  be  greatly  improved  by  the  adoption  of 
selected  non-technical  developments.  The  first  is  an  effort  to  promote  effective  transition  to 
industry,  the  likelihood  of  which  can  be  strengthened  by  early  recruitment  and  education  of 
champions  within  appropriate  DoD  and  commercial  sector  organizations.  Even  more  fundamental 
to  the  success  of  the  program  is  high  quality  user  documentation  for  all  classes  of  expected  users. 

The  document  details  a  number  of  needed  tasks  and  provides  suggestions  for  future 
considerations.  Mechanisms  for  EIS  evolution  and  technology  integration  are  discussed  in  some 
detail,  including  the  role  of  demonstrations,  standards  organizations,  and  early  technology 
application  into  particular  programs. 

The  need  for  an  EIS  capability  is  growing  with  each  technology  advances.  Future  efforts 
should  focus  on  opportunities  to  develop,  implement  and  integrate  EIS  technologies. 
Recommendations  resulting  from  this  study  include  the  following: 

a.  DoD  should  establish  EIS  development  and  implementation  priorities  based  on  the 
needs  of  targeted  application  domains. 

b.  DoD  should  expand  the  research  and  development  efforts  in  six  identified  EIS  related 
technology  areas. 

c.  DoD  should  investigate  opportunities  to  broaden  the  scope  of  the  EIS  program  through 
the  interaction  with  other  DoD  programs  and  additional  prototype  demonstrations. 
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1.  INTRODUCTION 


1.1  PURPOSE 


IDA  Document  D-693,  Interim  Status  and  Recommendations  for  the  Engineering 
Information  System  (E1S)  Program,  provides  an  analysis  of  the  EIS  framework  performed  by  the 
Institute  for  Defense  Analyses  (IDA).  IDA  evaluated  the  present  work  on  the  EIS,  made 
recommendations  for  improving  the  effectiveness  of  EIS  products,  and  identified  the  needed  tasks 
and  future  considerations.  This  document  is  the  result  of  tracking  the  program  implementation, 
starting  with  the  original  requirements  and  progressing  through  in-process  documents  produced 
for  the  EIS  program,  and  discussions  from  meetings  and  workshops  with  the  EIS  contractors  and 
Advisory  Committees. 


1.2  BACKGROUND 


The  original  requirements  documents  [Linn  et  al.  1986a,  1-1, 1-2]  described  the  problems 

faced  by  the  Department  of  Defense  (DoD): 

The  complexity  of  engineered  systems  is  increasing  dramatically.  Advances  in  the 
miniaturization  of  electronics  have  increased  the  complexity  of  electronic  designs 
by  an  order  of  magnitude  within  the  last  few  years.  Further,  the  advent  of  VHSIC 
technology  promises  to  increase  the  complexity  of  single-chip  designs  by  another 
order  of  magnitude. 

The  complexity  of  current  systems  already  is  so  great  that  it  would  be  practically 
impossible  to  carry  out  the  engineering  process  without  computer  assistance. 

Thus,  many  different  tools  and  support  systems  for  computer  aided  design  (CAD), 
computer  aided  manufacturing  (CAM),  computer  integrated  manufacturing 
(CIM),  and  (generically)  computer  aided  engineering  (CAE)  have  been  evolved 
and  continue  to  be  introduced.  Since  these  tools  essentially  shoulder  a  portion  of 
the  complexity  of  an  engineered  system,  the  amount  of  complexity  that  engineers 
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must  bear  is  substantially  reduced. 


Yet,  the  usefulness  of  these  tools  and  systems  is  reduced  in  the  current  situation 
since  no  particular  vendor  has  an  integrated  tool  set  that  performs  all  of  the  steps 
needed  and/or  desired  for  engineering  a  system  from  the  requirements  phase, 
through  specification  and  design,  all  the  way  to  manufacturing  and  maintenance. 
Thus,  the  creation  of  an  adequate  tool  set  requires  that  tools  from  different 
vendors  be  integrated  into  the  tool  set.  The  problem  here  is  that  tools  from 
different  vendors  utilize  different  models  and  formats  for  representing  the  same 
information  in  a  design.  Different  user  interfaces  are  employed;  similarly, 
different  approaches  are  used  in  implementing  administrative  and  management 
capabilities.  These  differences  create  additional  complexity  in  the  engineering 
process;  the  elimination  of  this  complexity  would  allow  the  potential  productivity 
gains  from  CAE  tools  to  be  more  fully  realized. 

A  second  problem  brought  about  by  the  increased  complexity  of  engineered 
systems  is  that  it  is  no  longer  possible  in  most  cases  for  a  single  engineer  to  design 
the  entire  system.  Rather,  complex  designs  must  be  subdivided  into  smaller  units 
and  the  designs  must  be  handled  by  design  teams  rather  than  by  individual 
designers. 


The  decomposition  of  a  design  often  creates  highly  interrelated  subtasks  that  must 
be  pursued  concurrently,  yet  the  designers  must  use  or  revise  each  other’s  results. 

Thus,  there  is  a  need  for  controlled  sharing  of  the  design  information,  tracking  of 
design  information,  tracking  of  design  dependencies  and  changes,  and  monitoring 
of  the  design  process.  In  short,  there  is  a  need  for  a  system  that  provides  database 
management  functions  for  engineering  information. 

In  response  to  these  problems,  an  Engineering  Information  System  (EIS)  was 
conceived  that  provides  a  framework  for  tool  integration  based  on  information 
sharing.  In  this  document,  the  term  EIS  is  used  to  describe  the  particular  system 
whose  concepts  and  requirements  are  defined  in  this  document  and  not  in  a 
generic  way.  Like  an  operating  system,  the  EIS  offers  facilities  and  defines 
interfaces  to  be  used  by  applications.  Also  like  an  operating  system,  the  EIS 
controls  and  allocates  resources  (here,  data  resources),  provides  concurrency 
controls,  archiving,  and  an  ad  hoc  query  capability. 

The  referenced  requirements  documents  have  established  the  need  for  the  following  basic 
EIS  functions: 

a.  Tool  Integration:  The  system  must  possess  the  ability  to  integrate  a  variety  of  tools 
with  different  data  and  hardware  requirements  in  an  efficient  and  uniform  manner. 


b.  Data  Exchange:  The  system  must  possess  the  ability  to  translate  and  communicate  data 
among  different  hosts  and  tools  within  an  EIS  as  well  as  between  the  EIS  and  external 
systems. 
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c.  Engineering  Management  and  Control:  The  system  must  incorporate  facilities  to 
monitor  the  design  process  and  to  impose  automatic  and  manual  controls  on  accessing 
and  modifying  data. 

d.  Information  Management:  The  system  must  incorporate  facilities  to  describe  and 
control  globally  ivailable  EIS  data  (including  the  creation  and  manipulation  of  data, 
the  imposition  of  data  validity  checking,  the  management  of  versions  and 
configurations,  the  control  of  concurrent  transactions,  and  the  management  of  backup 
and  archived  data.) 

e.  Administration:  The  system  must  incorporate  the  necessary  administrative  tools  and 
specifications  for  managing  the  data  dictionary,  other  tools,  workstations,  user 
profiles,  and  control  rules. 


2.  CURRENT  STATUS  OF  THE  PROGRAM 

2.1  PROGRESS  SUMMARY 

The  current  phase  or  the  EIS  program  was  based  on  the  set  of  requirements  developed  for 
the  Very  High  Speed  Integrated  Circuits  (VHSIC)  Program  Management  Office  by  an  EIS 
Requirements  Team  [Linn  et  al.  1986b,  2-1].  These  requirements  outlined  the  need  for  a  prototype 
demonstration  in  conjunction  with  a  large  set  of  short-term  (core),  extended  short  term  (high 
priority  but  not  mandatory  in  the  short  term),  and  long-term  EIS  requirements. 

The  initial  contractor  effort  has  been  to  develop  and  document  a  preliminary  design 
specification  for  the  EIS.  The  documentation  requirements  were  split  originally  into  three  major 
Contract  Data  Requirements  Lists  (CDPL’s)  deliverables  [USAF  1989a,  1989b,  1989c].  These 
three  CDRL  items  (titled:  Software  Top  Level  Design,  Interface  Design,  and  Database  Design) 
were  combined  and  delivered  as  a  single  document  titled:  Specification  for  Engineering 
Information  Systems.  This  document  is  divided  into  three  volumes.  Volume  I,  Organization  and 
Concepts,  describes  the  various  components  of  an  EIS  and  describes  how  those  components  fit 
together  and  behave.  Volume  II,  Specification  and  Guidelines,  defines  EIS  object  types  according 
to  a  common  template,  specifies  four  languages  developed  under  the  EIS  program,  and  established 
system  interfaces  (portability  primitives)  and  user  interface  guidelines.  Volume  III,  Engineering 
Information  Model  Administrative  Domain  and  ECAD  Domain  Model,  defines  a  model  for 
administrating  engineering  information  and  contains  an  Electronics  Computer- Aided-Design 
(ECAD)  domain  model  for  Integrated  Circuit  (IC)  design  data.1  This  preliminary  design  phase  was 

1.  The  three- volume  contract  deliverable  is  referred  to  in  this  document  as  the  EIS  design  specification. 
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presented  at  the  Final  Design  Review  by  Honeywell  at  the  Greenleaf  Conference  Center,  Florida 
on  November  14-16,  1989. 

The  EIS  program  is  now  moving  to  implementation  of  an  initial  prototype  phase.  The 
primary  advantage  in  moving  to  this  phase  (prototyping)  will  be  in  evaluating  the  collection  of  EIS 
requirements  and  effects  of  preliminary  design  decisions.  Initial  experimentation  with  tool  transfer 
and  interoperability  between  two  different  object-oriented  systems  will  then  be  possible. 

A  cross  reference  between  the  EIS  design  specification  and  the  IDA  requirements 
documents  [Linn  et  al.  1986a,  1986b]  has  now  been  compiled  and  made  available  by  the 
contractor,  however,  a  detailed  review  was  beyond  the  scope  of  this  effort  Although  the  current 
design  appears  to  comply  with  the  majority  of  the  IDA  requirements,  there  may  be  some  inefficient 
or  ineffective  (difficult  to  use)  interfaces.  It  is,  of  course,  not  practical  to  predict  the  performance 
of  such  a  complex  system.  However,  given  that  the  prototype  is  a  preliminary  design,  it  is  likely 
to  be  slow,  with  respect  to  other  (hard-wired  or  less  flexible)  engineering  environments.  This 
anticipated  condition  is  due  to  the  extra  overhead  driven  by  the  use  of  object-oriented  and  other 
generalized  interface  components. 

The  prototyping  will  not  result  in  a  complete  EIS.  Instead  it  will  focus  on  the  ECAD 
domain  and  will  support  continued  development  of  EIS  technology.  The  prototypes  will  allow 
users  and  managers  to  decide  on  the  value  of  the  EIS  concepts  as  a  whole,  to  assess  particular 
features  currently  specified  in  the  requirements,  to  review  deficiencies  in  selected  components  of 
the  current  design,  and  to  re-evaluate  the  EIS  requirements. 
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2.2  NEEDED  TASKS  AND  FUTURE  CONSIDERATIONS 

2.2.1  Areas  of  Concern 

2.2.1.1  Portability  Services 

Portability  services  revolve  around  using  the  Portable  Operating  System  for  computer 
environments  (POSIX),  X  Windows,  a  set  of  tools  and  Ada  bindings  for  X  Windows,  and  a  printer 
interface.  The  functions  of  POSIX  actually  used  by  the  EIS,  especially  by  the  higher-level  tools, 
should  be  enumerated.  The  issue  of  whether  windows  should  be  the  common  high-level  interface 
among  all  EIS  systems  must  be  addressed.  Similarly  the  policy  question  whether  each  installation 
develops  its  own  top-level  interface  must  be  addressed.  If  installations  develop  their  own  top-level 
interface,  then  the  User  Interface  Management  System  (UIMS)  would  fail  to  achieve  a  uniform 
EIS  that  operates  across  different  organizations  and  on  different  platforms.  This  could  effect  tool 
portability.  One  incentive  for  tool  developers  to  follow  the  UIMS  concept  would  be  to  provide  a 
small  set  of  parameterized  skeleton  tool  interfaces.  Tools  for  generating  adaptors  or  wrappers  for 
other  tools  should  be  addressed  also.  The  MOTIF  effort  may  achieve  this,  but  its  progress  must  be 
carefully  monitored. 

2.2.1.2  Object-Oriented  Paradigm 

The  use  of  the  object-oriented  paradigm  is  not  yet  proven  to  be  efficient  and  complete  in 
providing  all  the  necessary  views  for  a  large  running  system.  This  may  be  a  problem  because  in 
the  EIS  specification,  there  is  no  distinction  between  building  and  using  the  system.  Although  an 
object-oriented  approach  may  be  useful  in  prototyping,  it  is  not  obvious  that  it  will  be  effective  in 
production:  the  approach  may  be  difficult,  if  not  impossible,  to  configure  and  maintain  without 
management  mandated  control  over  the  schema,  its  objects,  procedural  elements,  etc.  No  large 
information  system  has  yet  been  implemented  using  such  a  “user  defined”  specification  and 
flexible  implementation  technique. 
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2.2.1.3  Coupling/Granularity  of  Objects 

There  is  a  legitimate  concern  over  the  appropriate  granularity  for  the  objects  contained  in 
the  EIS  object  base.  If  the  modeled  objects  are  very  low-level,  say  a  single  gate,  then  the  overhead 
of  storing  the  relationships  for  the  gate  in  the  object  base  and  the  overhead  of  accessing  a  design 
“gate-at-a-time”  may  outweigh  the  benefits  of  using  the  object  management  system  (OMS).  Con¬ 
versely,  higher  granularity  objects,  say  an  entire  gate  array,  would  overcome  these  objections; 
however,  one  could  not  then  use  the  OMS  functions  to  directly  query  at  a  gate  level.  The  important 
issue  is  how  this  tradeoff  should  be  balanced. 

2.2.1.4  Engineering  Environment  Services  (EES) 

The  EES  is  primarily  the  schema  for  the  Administration  domain.  The  Integrated 
Computer-Aided  Manufacturing  (ICAM)  Definition  model  version  IX  (IDEF-1X  model)  has  not 
been  validated,  and  the  correspondence  between  the  EES  specification  and  the  ability  to  express 
administrative  needs  should  be  checked  and  improved  as  necessary.  The  objects,  attributes,  and 
relationships  needed  for  the  EIS  prototypes  will  depend  on  the  application  scenario,  specific  tools 
choices,  and  the  scope  of  each  prototype.  The  EIM  needs  to  be  completed,  with  both  a  decomposed 
data  flow  model  and  an  IDEF-1X  object  model,  taking  account  of  whatever  tools  and  EES 
capabilities  are  in  the  prototypes.  This  model  is  simply  intended  to  document  features  that  are 
deemed  necessary  in  an  EIS. 

2.2.1.5  Implementation  Hierarchy 

The  specification  should  be  partitioned  into  an  implementation  hierarchy  of  user-group 
interfaces  with  a  careful  discussion  of  their  “maturity  as  a  term”.  There  should  be  an  enumeration 
and  timeframe  assessment  of  the  essential  activities,  including  an  explanation  of  the  trade-offs 
involved  in  including  or  excluding  a  portion  of  the  hierarchy.  This  will  entail  a  careful  discussion 
of  the  specific  need  for  each  interface  and  dependence  of  other  portions  of  the  specification  on  each 
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interface.  All  interfaces  are  obviously  not  at  the  same  level  of  risk.  Some  are  at  low  to  moderate 
development  risk,  with  their  architecture  and  implementation  obvious;  these  could  be  available  in 
one  to  two  years.  A  higher  level  of  difficulty  involves  industry  research  and  development  (R&D) 
where  implementation  should  be  possible  in  the  two-  to  three-year  time  frame.  The  interfaces  at 
the  highest  level  of  difficulty  are  probably  not  within  the  normal  industrial  workload,  and  would 
require  research  in  an  industrial  laboratory,  high  technology  company,  or  academia.  Such 
interfaces  would  need  from  three  to  ten  years  to  be  developed.  Because  implementing  and  using 
an  EIS  involves  interchange  of  tools,  it  appears  necessary  to  have  interchange  in  the  earliest 
prototypes.  However,  there  are  few,  if  any,  “EIS  Service  Tools”  specified  as  yet. 

One  of  the  major  problems  of  the  present  user  interface  is  its  apparent  lack  of  “user 
friendliness”.  The  user  of  a  design  must  be  knowledgeable  of  the  object  hierarchies  and  able  to 
deal  with  objects  at  a  micro-level.  For  example,  “register  and  deposit  a  new  tool  in  the  library”  or 
“implement  the  activities  of  the  IDEF  model”  would  require  many  function  calls. 

Also  required  is  a  prioritizing  of  object  types  and  methods  based  on  their  essential  nature 
to  the  EIS  application  domains  as  a  whole.  Prospective  vendors  or  providers  of  future  EIS  products 
could  develop  the  most  important  object  types  first  Such  analysis  would  illuminate  any 
unnecessary  appendages,  allowing  decisions  on  elements  that  are  not  essential  but  highly 
recommended.  Specification  of  EIS  components  which  are  essential  for  large  federated  systems 
include  many  interfaces  undergoing  standardization  or  which  are  candidates  for  standardization, 
e.g.,  recovery  and  concurrent  update  of  protocols  and  procedures,  methods  of  detecting  and 
protecting  from  deadlock  over  the  distributed  network,  and  distributed  schema  management. 

2.2.1.6  Multilevel  Security 

The  need  for  multilevel  security  in  the  running  EIS  must  be  considered.  Areas  that  should 
be  addressed  include  recommendations  on  special  evaluation  criteria,  additional  instrumentation 
required,  and  the  effect  on  implementation  and  system  performance.  Decisions  on  the  level  (B2, 
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B3,  or  even  Al)  could  have  far  reaching  effects. 

2.22  Specifications 

The  documentation  of  the  “core"  EIS  should  cover  such  topics  as  its  extensibility  to  more 
effective  systems  and  any  layering  needs,  types  of  tool  coupling  that  may  be  needed,  etc.  This 
should  be  application  domain  independent. 

The  content  and  format  of  the  EIS  design  specification  should  include  a  careful  statement 
of  the  relevance  of  the  specification  to  various  user  groupings:  framework  builders,  tool 
integrators,  managers,  and  end  users  who  need  to  understand  EIS  concepts  and  benefits.  Tailored 
interfaces  should  be  developed,  using  aggregates  of  objects,  to  simplify  actions  for  specific 
applications  or  user  domains.  Groups  will  have  different  criteria  for  their  successful  use  of  EIS. 
For  example,  EIS  users  are  likely  to  evaluate  the  interfaces  on  their  ease-of-use,  tool  vendors  to 
evaluate  the  EIS  interfaces  from  a  standpoint  of  effectiveness.  Tool  builders  will  need  easy  linkage 
to  other  tools  or  necessary  data  structures  and  also  will  need  to  tailor  the  actions  at  the  interface  to 
improve  efficiency  of  data  transfer. 

Additional  standard  or  default  auditing  and  management  control  needs  should  be 
enunciated.  The  specification  of  the  services  level  must  be  completed,  especially  those  interfaces 
that  are  needed  for  the  EES. 

Automated  electronic  publication  of  the  EIS  documentation  should  be  initiated.  Users 
could  then  use  retrieval  techniques  to  guide  their  queries.  Advanced  browsing  capabilities  for  the 
EIS  design  specification  (when  electronically  available)  would  greatly  expedite  development  and 
maintenance  tasks:  browsing  the  schema  from  a  user’s  perspective  has  not  yet  been  addressed.  The 
Data  Repository  will  be  built  using  objects  but  the  querying  mechanisms  to  be  used  have  not  yet 
been  specified. 

One  of  the  requirements  for  the  UIMS  is  flexibility:  the  users  are  to  be  allowed  to  specify 
their  interfaces.  However,  this  may  introduce  conflict,  because  there  is  also  the  need  to  have  the 
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same  look  and  feel  across  systems.  The  requirement  for  human  factors  interoperability  suggests  a 
common  interface  set,  but  it  would  not  be  economical  or  reasonable  to  insist  on  a  single  look  and 
feel  across  application  boundaries  unless  this  is  endorsed  by  standards  bodies.  There  should  be  a 
specification  of  a  possible  or  “proposed”  top-level  interface  that  would  include  launching  of 
applications  and  setting  user  roles,  possibly  as  an  expansion  of  the  Monitor’s  services.  This  might 
be  considered  a  user  shell. 

The  configuration  management  and  document  management  are  not  well  defined.  No 
configuration  management  tools  are  listed.  Standard  reports  and  descriptions  of  tools  for  merging 
information  are  needed.  The  EIS  also  should  provide  change  history  information  on  tools.  The 
specification  should  state  how  EIS  can  relate  similar  components.  The  ability  to  maintain  an  EIS 
will  be  a  mandatory  requirement  of  any  practical  system. 

The  Application  Object  Model  (AOM)  is  used  to  tailor  the  behavior  of  inherited  objects; 
the  Rule  Specification  Language  (RSL)  is  used  to  describe  rules  that  govern  the  (user-defined) 
automatic  triggering  of  responses  to  certain  stimuli.  However,  the  definition  of  the  AOM  in  the 
specification  seems  to  be  immature  and  incomplete.  Similarly,  the  definition  of  the  Rule 
Specification  Language  is  inadequate.  There  is  little  evidence  that  the  built-in  predicates  provide 
a  complete  or  consistent  base  definition.  Interim  rule  specifications  based  on  Object-Oriented 
Design  Language  (OODL)  are  likely  to  be  somewhat  inefficient  (Of  course,  rules  may  be  specified 
in  a  conventional  programming  language.  Such  a  technique  will  be  flexible  and  efficient  but  will 
be  relatively  inconvenient  and  less  maintainable  than  rules  specified  in  RSL.) 

2.23  Prototypes  and  Demonstrations 

The  planned  prototype  demonstration  should  be  reviewed  to  ensure  that  it  has  a 
sufficiently  broad  basis  to  address  perceived  major  problem  areas.  The  current  demonstration 
effort  should  attempt  to  focus  on  the  use  of  the  EIS  in  a  real  engineering  design  and  analysis 
environment.  Assessment  from  this  perspective  will  be  needed  for  program  management  decision 


making  on  future  EIS  technology  development.  Application  specific  questions  still  need  to  be 
addressed.  What  are  the  primary  technical  risks  in  the  EIS  concept?  What  are  the  economic  and 
other  resource  factors  issues  that  must  be  addressed  in  making  a  program  decision?  Is  any  current 
technology  limitation  a  barrier  to  success?  If  so,  will  this  change  with  time  in  the  near-term  without 
any  additional  effort  on  the  part  of  the  EIS  Program? 

Planning  for  technical  prototypes  and  for  demonstrations  of  EIS  benefits  in  specific 
application  domains  is  required.  The  prototype  demonstrations  should  consider  end-to-end  EIS 
testing  and  go  beyond  individual  vendor  interests.  It  should  also  include  discussion  of  the  goals, 
evaluation  criteria,  and  instrumentation  required,  including  reasons  for  selection  and  utilization  of 
software  and  discussion  of  tool  application  based  on  exiting  or  prototyping  standards,  such  as 
Computer-aided  Design  (CAD)  Framework  Initiative  (CFI). 

Configuration  dependency  maintenance  tools  are  needed  by  the  engineering  development 
and  maintenance  programs  to  address  EIS  performance  from  the  standpoints  of  both  compilation 
containment  and  the  flexibility  of  updating  approaches.  There  will  be  an  evolving  need  to  model 
the  configuration  structurally  without  dependencies  but  to  capture  the  fine  structure.  It  should  then 
be  possible  to  execute  functions  that  determine  if  one  object  is  actually  affected  by  a  change  in 
another.  For  example,  if  only  comments  were  changed  in  the  source  file,  the  Ada  or  VHSIC 
Hardware  Design  Language  (VHDL)  compiler  should  not  be  invoked. 

The  plan  for  the  prototype  demonstration  and  the  plan  for  the  subsequent  evaluation 
process  should  focus  on  specific  near-term  EIS  objectives  and  needs.  The  following  paragraphs 
highlight  specific  technical  areas  that  these  plans  should  address.  The  results  of  the  prototype 
demonstration  should  not  only  be  used  to  demonstrate  feasibility,  they  should  be  used  to  support 
an  iterative  design  and  system  maturation  process. 

Two  EIS  interface  languages  are  Script  Definition  Language  (SDL),  a  set  machine 
description  language,  and  Interaction  Object  Definition  Language  (IODL),  a  sub-language  of  SDL. 
Their  motivation  and  jusdfication  are  not  explicitly  stated  in  the  design  documentation,  though 


12 


they  are  obviously  intended  to  capture  the  behavioral  requirements  of  the  UIMS.  They  carry  a  risk, 
as  do  many  other  features,  since  SDL  is  untried.  All  EIS  tools  are  supposed  to  use  UIMS  during 
integration  of  their  tools  into  the  EIS.  SDL  is  based  on  Event-Driven  Transition  Systems,  and 
though  state  machines  are  a  common  user  interface  model,  they  are  often  too  constraining. 

The  Common  Exchange  Format  (CEF)  should  be  used  to  demonstrate  transmission  of 
data,  such  as  images  of  even  binary  files  using  standard  non  EIS  base  types.  There  will  be  a  need 
for  special  tools  that  will  have  to  be  developed  to  restore  image  or  binary  files.  Electronic  Design 
Interchange  Format  (EDIF),  the  VHSIC  formats,  and  IPC  all  have  their  own  semantics.  They  are 
fully  expressible  in  object  format.  Though  CEF  is  general,  specific  translators  would  have  to  be 
constructed  to  aid  the  user  in  moving  from  CEF  to  EDIF  and  back,  etc.  In  addition,  they  may  differ 
in  kind,  e.g.,  for  EDDF  the  translator  can  only  cover  EDIF-based  domains. 

The  Engineering  Information  Model  (EIM)  covers  a  very  specific  EC  AD  database 
description  for  detailed  design  and  layout.  It  must  be  extended  for  broad-based  EC  AD  scenarios. 
Only  the  ECAD  model  domain  is  currently  supported  in  the  EIS  design;  there  is  no  current 
(funded)  plan  to  move  from  this  to  other  domains,  though  the  interaction  proposed  with  PDES  test 
benches  may  help  to  alleviate  this. 

The  implementation  should  be  beneficial  to  all  programs.  In  addition  to  the  objects, 
attributes,  and  relationships  needed,  the  EIM  should  include  the  complete  definition  of  functions 
pertinent  to  each  object  for  supporting  the  scenario  pertaining  to  microcircuit  ECAD  physical 
design  and  layout;  the  EIM  should  also  identify  specific  commercial-off-the  -shelf  (COTS)  tools 
to  be  integrated.  The  scenarios  should  cover  EIS  attachment  to  a  conventional  PDES  relational 
database  server  which  holds  instances  of  electronic  item  data.  Also,  these  scenarios  should  be 
detailed  sufficiently  so  as  to  reveal  most  of  the  user  operations. 

2.2.4  Dissemination  of  EIS  Technology 

The  dissemination  of  the  EIS  technology  is  critical  to  the  future  viability  of  an  EIS  type 
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system  necessary  to  meet  the  design  environment,  support  and  evalutionary  needs  of  increasingly 
complex  systems.  Based  on  this  critical  need  the  EIS  Program  should  pursue  the  following  actions: 

a.  Develop  a  plan  for  technology  application  and  integration,  using  technical  and  popular 
articles,  and  presentations  at  conferences  on  engineering  and  information  systems. 

b.  Coordinate  with  major  engineering  and  management  initiatives  within  DoD  such  as  the 

Computer-Aided  Logistics  System  (CALS),  concurrent  engineering,  integrated 
diagnostics,  weapon  systems  development  programs,  and  with  industry  and 
Government  standards  organizations  by  proposing  new  national  and  international 
standards.  For  example,  the  ECAD  model  is  neither  validated  nor  accepted  by  any 
standards  body;  ensuring  acceptance  in  this  sense  must  also  be  an  active  effort 

c.  Develop  and  manage  a  road  map  for  EIS  technology  improvement  and  insertion. 
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3.  OPPORTUNITIES  FOR  El S  EVOLUTION  AND  TECHNOLOGY 
INSERTION 


This  section  discusses  the  opportunities  for  EIS  technology  insertion  and  application 
through  prototypes  and  demonstrations,  support  from  standards  organizations,  and  targeted 
implementation  in  on-going  program  areas. 


3.1  USE  OF  PROTOTYPES  AND  DEMONSTRATIONS 


The  EIS  prototype  will  represent  the  first  opportunity  for  EIS  technology  application.  In 
addition  to  demonstrating  the  feasibility  of  the  EIS  concept,  it  will  allow  users  first-hand 
experience,  answer  questions  regarding  large  systems  implementation,  and  provide  a  test  bed  for 
tool  vendors.  Recognizing  that  some  of  the  technology  is  closer  to  basic  research  than 
development,  many  tool  vendors  will  avoid  the  potential  risks  associated  with  technology  insertion 
until  benefits  have  been  demonstrated. 

Therefore,  future  prototyping  should  address  representative  sets  of  EIS  System 
Administrator  tools  necessary  for  installing,  operating,  and  maintaining  the  EIS.  Multiple 
prototyping  efforts  should  be  considered  to  demonstrate  effective,  non-laborious  ways  for  the 
Administrator  to  set  up  controls  for  user  and  server  interfaces,  establish  and  control  multiple 
disparate  views,  modify  the  Installation  Schema  (while  maintaining  object  base  or  adapter 
integrity  accordingly),  and  initialize,  monitor,  and  recover  the  EIS  system  in  spite  of  hardware  or 
software  failure. 

Prototyping  provides  opportunities  to  investigate  alternative  interfaces,  with  particular 
attention  given  to  reference  Schema  extension,  use  of  COTS  tools  common  to  the  prototypes  and 
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current  Product  Data  Exchange  Specification  (PDES)  test  bed,  and  CEF  interchange  of  product 
description  data.  ( 

The  implementation  of  EIS  Prototypes  will  ultimately  benefit  a  number  of  programs.  In 
addition  to  the  objects,  attributes,  and  relationships  needed,  the  EIM  will  eventually  include  the 
complete  definition  of  functions  pertinent  to  each  object  for  supporting  microcircuit  EC  AD  < 

physical  design  and  layout  Prototype  application  EIM’s  will  also  help  identify  specific  COTS 
tools  for  integration.  Future  prototyping  scenarios  should  cover  EIS  integration  of  conventional 
relational  database  servers  which  hold  instances  of  microcircuit  reference  data  or  hosts  ECAD  ( 

application  tools.  This  will  provide  opportunities  for  designs  to  be  detailed  or  decomposed  to  a 
point  where  most  of  the  user  operations  are  revealed. 

) 

3.2  SUPPORT  FROM  STANDARDS  ORGANIZATIONS 

A  recommended  approach  for  technology  insertion  is  to  evaluate  components  of  the  EIS 
for  potential  standardization  and  establish  potential  ways  for  implementing  the  process.  Standards  { 

can  reduce  overhead  and  maintenance  costs,  provide  consistency,  and  increase  productivity.  No 
single  vendor  possesses  the  best  total  solution  —  thus  it  is  necessary  to  produce  standard  interfaces 
and  buy  tools  that  use  this  though  a  free  market  model.  < 

An  EIS  framework  for  standards  development  requires  a  core  of  EIS  which  is  application 
insensitive  and  upon  which  application  views  can  be  configured.  Standards  organizations  such  as 
the  American  National  Standards  Institute  (ANSI)  seldom  develop  the  material.  Ad  hoc  bodies  do  I 

so,  but  this  then  requires  a  transition  phase.  Figure  1  depicts  a  model  of  the  EIS  standards  interface; 
apart  from  the  UIMS  area  shown  shaded,  standards  development  takes  place  in  the  generic 
environment  of  the  core.  Then  the  application-specific  standards  can  be  developed  by  other  (or  ( 

even  the  same)  body. 

The  EIS  contractor  should  be  encouraged  to  interact  continuously  with  the  Contracting 
Officer’s  Technical  Representative  (COTR)  to  identify  and  recommend  appropriate  standards 
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initiatives.  This  should  include  the  boundary  (or  boundaries)  of  the  EIS  core  and  ways  of  providing 
particular  application  views. 


Figure  1.  A  Model  of  the  EIS  Standards  Interface. 


A  possible  impediment  to  satisfactory  standards  development  for  an  integrated  activity 
such  as  the  EIS  is  the  present  nature  of  standards-making  bodies.  Very  little  overlap  is  observed 
between  similar  working  groups  in  separate  organizations.  There  should  be  a  single  congruent 
model  of  the  recommended  prime  standard  for  engineering  activities.  DoD  leadership  might 
consider  joint  sponsorship  of  allied  working  groups,  as  this  could  have  significant  pay-off, 
especially  where  one  group  currently  creates  the  standard  document  which  another  ratifies.  For 
example,  CFI  could  lead  the  standards  strawman  development  effort  and  address  objections,  while 
the  Design  Automation  Standard  Subcommittee  (DASS)  could  ballot  and  ratify  the  standard, 
preferably  with  the  same  working  group  participants.  Such  efforts  may  start  with  a  simple 
memorandum  of  understanding  and  progress  further  later. 


Four  basic  representations  are  reflected  in  the  overall  model  in  Figure  1 .  These  are  the 
information  model,  a  reference  schema  generation  method,  procedural  binding  for  non-object  style 
programming  of  tools  and  user  interfaces,  and  one  or  more  process  reference  models.  But  there  is 
still  need  for  a  conceptual  model  to  have  a  common  definition  across  all  standards,  including  a 
common  glossary  of  terms  and  an  agreement  between  groups  on  the  focus. 

The  need  for  Computer-Aided  Software  Engineering  (CASE)  and  information 
requirement  standards  is  great  for  expressing  the  future  requirements.  The  transfer  of  EIS  data, 
models,  and  final  designs  demand  mutual  agreement  between  standards  organizations  and  EIS 
component  vendors. 

3.3  IMPLEMENTATION  IN  PROGRAM  AREAS 

Many  parts  of  the  EIS  have  interfaces  that  are  useful  to  DoD  and  other  Government 
programs  as  well  as  the  industrial  sector  (via  Nauonal  Institute  of  Standards  and  Technology 
(NIST),  PDES  Inc.,  etc.).  Such  interfaces  are  illustrated  in  Figure  2,  which  is  also  annotated  with 
the  main  strawman  inputs  from  the  EIS  efforts  to  standards  bodies. 

Current  products  of  the  EIS  program  are  the  generic  engineering  information  management 
system  specification  and  the  specific  information  model  for  microcircuit  electrical  design  (ECAD). 
Future  EIS  products  and  development  efforts  should  include  the  following: 

a.  Usable  EIS  prototypes  with  an  object  management  capability  and  object-oriented 
system  tools  to  allow  further  demonstration  with  the  prototypes. 

b.  Validated  specifications  and  guidelines  for  implementation  of  EIS  environments. 

c.  Validated  installadon  schema  development  methodology  that  can  be  tailored  to  any 
required  user  development  methodology.  A  complete  example  must  be  provided  to 
show  the  generalized  methods  and  capabilities,  as  well  as  the  resulting  products,  such 
as  the  documents  to  act  as  guidelines. 
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d.  Default  EES  for  engineering  applications  Administration  Reference  Schema  and 
support  tools  to  provide  an  initial  capability  for  prototype  users. 

e.  A  tool  wrapper  generator,  with  examples  of  developed  specific  tool  wrappers  and  a  set 

of  guidelines  on  methods  and  means  of  invocation  of  procedures  in  scenarios  that 
illustrate  the  addition  of  tools,  etc. 
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4.  PROGRAM  RECOMMENDATIONS 


4.1  ESTABLISH  DEVELOPMENT  PRIORITIES 

The  EIS  Specification  appears  challenging  to  implement.  Therefore,  DoD  should  establish 
priorities  for  each  portion  of  the  EIS  to  determine  which  components  should  be  built  first  and 
which  are  optional.  From  a  long  term  DoD  perspective,  the  highest  priority  items  are  application 
independent  such  as  the  object  management  system  (OMS),  configuration  manager,  security 
objects,  and  portability,  services.  However,  for  the  EIS  to  be  applied  productively,  it  must  have  the 
ability  to  interface  with,  and  support  communications  between,  specific  application  domain  tools. 
Consequently,  additional  implementation  priorities  should  be  established  based  on  the  needs  of 
targeted  application  domains  that  are  critical  to  development  and  support  of  DoD  system  as  well 
as  standardization  initiatives.  See  Figure  2  for  illustration  of  potential  users. 

4.2  R&D  EFFORTS  REQUIRED  FOR  FUTURE  EIS 

As  discussed  in  the  Background  section,  there  exists  a  compelling  need  to  integrate  the 
engineering  design,  development,  production,  support  and  evaluation  information  across  a  variety 
of  automated  tools.  However,  several  of  the  technology  areas  necessary  to  evolve  and  mature  an 
EIS  system  require  focused  research  and  development  The  following  recommended  R&D  areas 
are  critical  to  future  EIS  evolution: 

a.  Development  and  integration  tools  to  support  EIS  development  and  use. 

b.  Automation  techniques  for  generation  of  reference  schema  from  information  models. 
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c.  Development  of  a  variety  of  interface  sets  for  distinct  user  groupings. 


d.  Development  of  performance  models  for  federated  and  workstation  environments. 

e.  Development  of  a  security  model  for  federated  systems  and  workstations. 

f.  Development  of  federated  information  models  to  incorporate  existing  non-information 

models  and  standards  for  various  application  domains. 

4.3  EXPAND  PROGRAM  SCOPE 

Due  to  significant  long  term  benefits  and  payoffs  that  will  result  from  a  mature  EIS 
capability,  DoD  should  reassess  the  scope  of  the  current  program  and  investigate  opportunities  to 
broaden  the  implementation  of  EIS,  specifically  the  EIS  program  Office  should: 

a.  Investigate  the  needs  and  requirements  of  other  DoD  programs  and  ongoing  initiatives 
that  have  the  need  to  integrate  tools  and  information  from  a  variety  of  sources,  and 
propose  prototype  demonstrations  for  the  specific  target  domains. 

b.  Provide  technical  assistance  in  the  technology  integration  and  application  of  EIS 
technologies. 

c.  Establish  specific  memoranda  of  agreement  with  other  programs  and  between 
individual  programs  whose  mutual  technical  benefits  can  be  achieved.  The 
interrelationships  and  potential  benefits  are  illustrated  in  Figure  2. 

d.  Develop  an  overall  plan  for  the  services  and  DoD  to  propose,  validate,  and  implement 

critical  “core”  EIS  interface  standards  that  will  facilitate  the  integration  of  different 
vendor’s  tool  sets  over  a  broad  range  of  electrical,  mechanical  and  software  domains. 
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APPENDIX  A  -  MINI-SCENARIOS  FOR  COOPERATION  AND 


TECHNOLOGY  INSERTION 

Standard  interfaces  frequently  reduce  overhead  and  maintenance  costs  of  purchased  tools 
and  other  software,  while  providing  consistent  framework  and  improving  productivity.  No  single 
vendor  possesses  all  of  the  best  and  accepted  solutions;  thus  it  is  necessary  to  acquire  tools  that 
interface  and  interact  correctly.  Consequently,  it  is  valuable  and  cost-effective  for  the  DoD  to 
support  standards  activities.  Furthermore,  as  systems  become  more  complex,  integrated 
engineering  information  design  environments  become  a  necessity. 

This  appendix  addresses  possible,  interactions  and  informal  arrangements  between  EIS 
and  important  related  groups  generally,  standards  bodies  and  other  large  DoD  R&D  efforts.  The 
preferred  approach  to  EIS  technology  insertion  suggested  in  this  section  is  intended  to  focus  on 
demonstration  and  prototyping  efforts  that  yield  mutual  benefits  to  all  participating  parties. 
Specific  discussion  of  demonstrations  and  prototyping,  and  of  development  of  new  technology  for 
insertion  into  for  the  EIS  are  addressed  in  other  parts  of  the  document.  Discussions  here  are, 
therefore,  intended  to  serve  as  catalyst  for  major  associated  standards  and  industry  groups  and  to 
promote  the  insertion  by  transitioning  technology  to  other  DoD  efforts. 

1.  SUPPORT  OF  VARIOUS  STANDARD  AND  INDUSTRY  BODIES 

Several  standardization  and  industrial  consortia  efforts  are  currently  being  supported 
under  the  EIS  contract: 

a.  CFI  and  CFL 

CAD  Framework,  Inc.  (CFI)  is  a  consortium  of  Computer-Aided  Design  (CAD)  users  and 
vendors  dealing  with  the  transfer  of  data  between  tools.  The  standards  activities  are  through  a 
bottom-up,  consensus-based  operation.  CFI  is  creating  a  model  for  EDA  tools  and  firmware 
environments  to  integrated  system  solutions.  They  will  demonstrate  a  simple  six-item  netlist 
model  as  an  illustration  of  their  concept  at  the  Design  Automation  Conference  (DAC)  in  June 
1990.  This  will  show  that  different  vendors  can  produce  and  apply  an  agreed-upon  model.  The 


effort  is  currently  under  the  direction  of  Microelectronic  Computer  Corporation  (MCC)  personnel. 
MCC  is  also  taking  the  active  role  in  development  of  the  CAD  Framework  Lab  (CFL),  which  will 
test  and  evaluate  the  CFI  strawman  standards.  Now  that  MCC  is  a  member  of  the  E1S  Team, 
opportunities  for  EIS  technology  transfer  to  CFI  and  the  CFL  should  be  improved, 
b.  PDES 

PDES  activities  have  centered  on  product  descriptions  for  mechanical  design.  PDES  will 
extend  activities  into  the  electrical  domain,  working  with  national  standards  organizations  (e.g, 
Institute  of  Electronics  and  Electrical  Engineers  (IEEE),  Electronics  Industries  Association 
(ELA)).  The  various  standards  development  organizations  for  PDES  product  information  will 
express  the  components  of  PDES  in  a  language  conforming  to  existing  standards  efforts,  but  then 
will  convert  or  relate  semantic  components  to  a  common  integrated  information  model  (using  the 
Express  language). 

(1)  PDES  voluntary  is  a  group  supporting  the  development  of  PDES  electrical  in  the 
Electrical  Application  Committee,  using  the  PDES  Information  Modeling 
Methodology. 

(2)  ANSI  PDES  Electrical  Engineering  standards  are  now  under  the  guidance  of  an 
organization  with  a  board  consisting  of  EIA,  IEEE,  Institute  for  Interconnectivity 
and  Packaging  Electronic  Circuits  (IPC),  andAmerican  Society  of  Mechanical 
Engineers  (ASME).  Task  groups  will  typically  work  in  the  information  model 
language,  integrated  model,  implementation,  validation  &  test,  and  standards 
taxonomy. 

(3)  PDES  Inc.  is  providing  industrial  validation  of  PDES  standards.  The  national 
PDES  electrical  effort  will  be  guided  by  subcommittees,  reporting  to  ANSI.  The 
PDES  committee  has  two  active  subcommittee  members  from  the  EIS  team. 

(4)  NIST  is  providing  a  PDES  testbed.  At  present  there  are  discussions  regarding  the 
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integration  of  an  EIS  prototype  into  the  NIST  PDES  testbed.  EIS/ECAD  model 
extensions  also  should  be  integrated  with  the  PDES  models.  This  effort  could 
yield  a  multidomain  demonstration. 

c.  IEEE/DASS 

DASS  is  chartered  to  provide  standard  descriptions  for  capture,  utilization,  and 
communications  of  electrical  engineering  design  data.  It  handles  system  to  layout  levels  of  design. 
The  IEEE/DASS  effort  is  an  actual  standardizing  organization  (i.e.,  they  take  developed  proto¬ 
standards  and  ratify  them).  Thus  CFI’s  strawman  effort,  having  developed  the  proposed  standard 
and  addressed  any  early  objections,  could  pass  the  final  drafts  to  DASS  for  final  balloting  and 
ultimately  ratification  of  the  standard.  Current  work  being  supported  under  EIS  therefore  includes 
routing  PDES  and  CFI  strawman  standards  to  the  IEEE/DASS  standards  process.  At  present  two 
subcommittees  are  staffed  by  EIS  contractor  personnel.  Efforts  should  continue  to  support  models 
and  frameworks. 

d.  Semantic  level  portability  Services  (EDIF,  CDIF,  etc.) 

CASE  and  information  requirement  (e.g.,  IDEF-like)  standards  are  good  for  expressing 
system  requirements.  Transfer  of  EIS  data,  models,  and  final  designs  demand  mutual  agreement 
between  standards  organizations  and  EIS  component  vendors.  Although  the  CFI  will  provide 
low-level  interchange,  higher  order  semantics  are  possible  using  other  protostandards. 
EDIF  and  CDIF  are  two  EIA-sponsored  standardizing  bodies  developing  standards  for 
interchange  of  electronic  circuit  and  software  engineering  (CASE)  tool  information.  The  latter 
effort  is  also  being  considered  by  the  IEEE  Computer  Society  Task  Force  on  Professional 
Computing  Tools. 

e.  MOTIF,  OPEN/LOOK,  and  other  UIMS  Prestandards 

There  are  several  pre-standardization  organizations  addressing  the  issue  of  the  user 
interface,  e.g.,  MOTIF,  OPEN/LOOK,  and  the  Athena/X  consortium.  Their  work  should  be 
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monitored,  but  until  there  are  positive  recommendations  from  them,  the  design  of  interfaces  effort 
should  probably  be  left  to  specific  vendor  implementations  or  general  workstation  industry 
standards. 

2.  FEDERAL  SUPPORTED  EFFORTS 

Many  major  DoD  and  other  Governmental  efforts  have  common  requirements  for  data 
interchange,  both  for  transfer  between  contractor  and  vendors  and  for  dissemination  of  various 
documents,  design  layouts.  Ones  specifically  showing  interest  in  EIS  products  at  present  include 
the  following: 

a.  Microwave  and  Millimeterwave  Monolithic  Integrated  Circuits  (MIMIC) 

The  MIMIC  office  at  Ft.  Monmouth  is  supporting  the  development  of  CAD  environments 
for  MIMIC  circuits;  they  intend  to  choose  two  frameworks  as  their  approved  CAD  platforms.  They 
would  like  to  use  the  EIS  concepts  in  achieving  standardization  of  their  CAD  environments. 
Current  plans  involve  extension  of  the  ECAD  model  to  support  analog  devices  and  then  to  build  a 
demonstration  using  MIMIC  tools  operating  to  the  model.  One  of  the  current  frameworks 
(Cadence  or  Silicon  Compilers)  would  probably  be  used  in  this  demonstration,  and  it  would  then 
be  migrated  as  the  EIS  platform. 

b.  Microelectronics  Manufacturing  Science  and  Technology  (MMST) 

The  MMST  Program  Office  would  like  to  integrate  the  EIS  and  MMST  technologies  to 
aid  in  efficient  design-to-manufacture  transition  for  IC.  The  EIS  ECAD  model  can  be  integrated 
with  the  MMST  information  models  and  then  the  EIS  prototype  could  be  combined  with  the 
MMST/CIP  processors  to  achieve  this.  It  might  even  be  possible  to  use  the  EIS  framework 
technology  in  CIP  to  achieve  this  result  also. 

c.  Logistics  R&D  Efforts 

Retrofit  engineering  projects  are  underway  at  various  Air  Force  Air  Logistics  Centers 
(ALC).  They  have  a  need  for  common  repository  and  data  exchange  technology  and  tools,  and  feel 
that  the  EIS  framework  and  modeling  technologies  provide  a  possible  solution.  A  demonstration 
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scenario  would  include  model  extensions  to  different  life  cycle  phases  and  an  integrated 
environment  for  design  and  support  phases  and  interface  to  manufacturing. 

( 1 )  Sacramento  ALC  is  undertaking  development  of  a  logistics  retrofit  process  activity 
for  gate  arrays  and  VHSIC. 

(2)  'Vamer-Robbins  ALC  is  undertaking  some  specific  retrofit  projects  (RFP).  They 
need  an  appropriate  design  and  lifecycle  support  environment. 

d.  JIAWG 

The  Joint  Interoperable  Avionics  Working  Group  (JIAWG)  is  a  tri-service  operation 
dedicated  to  providing  efficiency  in  avionics  procurement  through  reuse  of  avionics  hardware  and 
software.  This  is  being  showcased  through  the  program  offices  for  the  ATF  (Air  Force),  the  ATA 
(Navy),  and  LHX  (Army).  An  EIS  is  needed  to  integrate  avionics  systems  as  the  individual 
environments  are  defined.  The  common  component  libraries  and  their  specifications  must  be 
indexed  and  managed  by  such  a  system  as  a  precondition  to  practical  reuse  of  both  hardware  and 
software  components.  This  requires  an  extension  of  the  domain  information  model,  integrating 
tools,  populating  repositories  with  parts,  and  developing  a  demonstration  scenario.  It  is  important 
for  EIS  personnel  to  coordinate  with  JIAWG  to  avoid  duplication  of  effort,  contribute  to  the 
success  of  the  interoperability  initiative,  and  provide  a  demonstration  of  EIS  effectiveness. 

e.  Software  Technology  for  Adaptable,  Reliable  Systems  (STARS) 

The  STARS  program,  now  located  within  the  Information  Sciences  Technology  Office 
(ISTO)  of  DARPA,  has  endorsed  the  concept  of  establishing  an  effective  functional  prototyping 
technology  and  process  to  articulate  the  software  cost/benefit  trade-off  alternatives.  Among  the 
other  benefits  of  taking  an  EIS  approach  to  integrated  hardware/software  systems  is  concurrent 
development  of  hardware  and  software  for  improved  allocation  of  functionality  and  more  efficient 
and  effective  integration,  integrated  diagnosis/support  platforms,  and  sharing  of  repositories  for 
hardware  and  software  designs. 


f.  NASA  Space  Station 


The  work  at  NASA  in  Reston  and  Houston  in  developing  the  Space  Station  information 
systems  is  yet  another  effort  dealing  with  large  back-plane  environment  developments  for 
interchange  of  design,  configuration,  and  runtime  data.  In  addition,  there  are  software  support  and 
production  environments  and  Technical  and  Management  Information  Systems.  As  a  massive 
systems  development  and  integration  project,  the  Space  Station  can  benefit  from  DoD  EIS  activity, 
provide  further  potential  tests  and  applications  of  EISs,  and  promote  technology  transfer.  Both 
DoD  and  NASA  would  gain  from  cross  fertilization  of  ideas  if  not  integration  of  some  efforts.  EIS 
representatives  should  develop  and  maintain  contacts  with  NASA  Space  Station  projects, 
g.  SDI 

The  development  and  simulation  environments  of  the  Strategic  Defense  Institute  (SDI) 
have  many  problems  in  common  with  the  development  of  multi-vendor  engineering  systems.  In 
many  ways,  they  are  similar  to  the  Space  Station  developments  mentioned,  in  that  they  involve  the 
development  and  deployment  of  unprecedented  mission  critical  systems  requiring  massive 
integration,  fault  detection  and  repair,  and  long-term  maintenance  and  evolution  in  an  extremely 
difficult  environment.  There  should  be  some  liaison  with  EIS,  as  this  projected  system  involves  a 
degree  of  complexity  that  requires  the  use  of  engineering  information  systems. 


28 


APPENDIX  B  -  ACRONYMS 


ALC 

ANSI 

AOM 

ASME 

CAD 

CAE 

CAIS-A 

CALS 

CAM 

CASE 

CDIF 

CDRL 

CEF 

CFl 

CFL 

CIM 

COTS 

COTR 

CSED 

DARPA 

DAC 

DASS 

DICE 

DoD 

ECAD 


Air  Logistics  Center 

American  National  Standards  Institute 

Application  Object  Model 

American  Society  of  Mechanical  Engineers 

Computer-Aided  Design 

Computer-Aided  Engineering 

Common  Ada  Programming  Support  Environment  (APSE)  Interface  Set  - 
[version]  A 

Computer-Aided  Logistics  System 
Computer-Aided  Manufacturing 
Computer-Assisted  Software  Engineering 
CASE  Design  Interchange  Format 
Contract  Data  Requirements  List 
Common  Exchange  Format 

Computer-Aided  Design  (CAD)  Framework  Initiative 
Computer-Aided  Design  Framework  Laboratory 
Computer-Integrated  Manufacturing 
Commercial  Off-the-Shelf  Software 
Contracting  Officer’s  Technical  Representative 
Computer  and  Software  Engineering  Division 
Defense  Advanced  Research  Projects  Agency 
Design  Automation  Conference 
Design  Automation  Standard  Subcommittee 
DARPA  Initiative  in  Concurrent  Engineering 
Department  of  Defense 
Electrical  Computer-Aided  Design 
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ECLIPSE 

EDIF 

EES 

EIA 

EIM 

EIS 

ICAM 

IDA 

IDEF 

IEEE 

IMIS 

IMM 

10 

IODL 

IPC 

ISO 

JIAWG 

LRM 

MCC 

MIMIC 

MMST 

NASA 

NCGA 

NIC 

NIST 

OMS 


Electric  Capability  for  the  Logistics  Information  and  Product  Support  for 
Electronics 

Electronic  Design  Interchange  Format 
Engineering  Environment  Services 
Electronics  Industry  Association 
Engineering  Information  Model 
Engineering  Information  System 
Integrated  Computer-Aided  Manufacturing 
Institute  for  Defense  Analyses 
ICAM  Definition  Method 
Intitute  for  Electronics  and  Electrical  Engineers 
Integrated  Maintenance  Information  System 
Information  Modeling  Methodology 
Interaction  Object 

Interaction  Object  Definition  Language 

Institute  for  Interconnectivity  and  Packaging  Electronics  Circuits 

International  Standards  Organization 

Joint  Interoperable  Avionics  Working  Group 

Line  Replaceable  Module 

Microelectronic  Computer  Corporation 

Microwave  and  Millimeterwave  Monolithic  Integrated  Circuits 

Microelectronic  Manufacturing  Science  and  Technology 

National  Aeronautics  and  Space  Administration 

National  Computer  Graphics  Association 

Non-Interative  Components 

National  Institute  of  Standards  and  Technology 

Object  Management  System 
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OODL  Object-Oriented  Design  Language 


PCTE  Portable  Common  Tool  Environment 

PDES  Product  Data  Exchange  Specification 

POSIX  Portable  Operating  System  for  Computer  Environments 

R&D  Research  and  Development 

RAMP  Rapid  Area  Manufacturing  Program 

RSL  Rule  Specification  Language 

SDI  Strategic  Defense  Initiative 

SDL  Script  Definition  Language 

SSE  Space  Station  Environment  (NASA) 

STARS  Software  Technology  for  Adaptable,  Reliable  Systems 
TISSS  Tester  Independent  Software  Support  System 

UIMS  User  Interface  Management  System 

VHDL  VHSIC  Hardware  Design  Language 

VHSIC  Very  High  Speed  Integrated  Circuits 


i 


) 


I 


31 


APPENDIX  C  -  REFERENCES 


Honeywell  et  al.  1989.  Specifications  for  Engineering  Information  Systems.  Three  Vol¬ 
umes.  Minneapolis,  MN:  Honeywell.  CNF33615-87-C-1401 

Linn,  Joseph  L.  et  al.  1986a.  The  Department  of  Defense  Requirements  for  Engineering 
Information  Systems  (EIS).  Volume  I:  Operational  Concepts.  Alexandria,  VA:  Institute  for  Defense 
Analyses.  NTIS  AD-A176  153. 

Linn,  Joseph  L.  et  al.  1986b.  The  Department  of  Defense  Requirements  for  Engineering 
Information  Systems  (EIS).  Volume  II:  Requirements.  Alexandria,  VA:  Institute  for  Defense  Anal¬ 
yses.  NTIS  AD-A176  154 

U.S.  Air  Force.  1989a.  Software  Top  Level  Design  (CDRL  13).  Wright-Patterson  AFB, 
OH.  CN  F33615-87-C-140I. 

U.S.  Air  Force.  1989b.  Interface  Design  ( CDRL  16).  Wright-Patterson  AFB,  OH.  CN 
F33615-87-C-1401. 

U.S.  Air  Force.  1989c.  Database  Design  (CDRL  17).  Wright-Patterson  AFB,  OH.  CN 
F33615-87-C-1401. 


Proposed  Distribution  List  for  IDA  Document  D-693 


NAME  AND  ADDRESS 


Sponsor 

Mr.  Martin  Meth 
Director,  WSIG 
OASD(P&L) 

Room  2B322 
The  Pentagon 
Washington,  DC  20301 

Other 

Defense  Technical  Information  Center 
Cameron  Station 
Alexandria,  VA  22314 

Mr.  Howard  Bloom 

National  Institute  for  Standards  and  Technology 
(NIST) 

Gathersburg,  MD  20899 

Col  John  M.  Borky 
ASD/YFA 

Wright  Patterson  Air  Force  Base,  OH  45433 

Mr.  Charles  D.  Bosco 
US  Army  LABCOM 
ATTN  SLCET-IC 
Fort  Monmouth,  NJ  07703-5302 

Ms.  Lorna  Carmichael 

US  Army  Laboratory  Command 

ETDL 

ATTN  SLCET-MP-W 

Fort  Monmouth,  NJ  07703-5000 

Dr.  Elliot  Cohen 
DARPA,  DMO 
1400  Wilson  Blvd 
Arlington,  VA  22209 

Mr.  Bert  Cream 
AFHRL/LR 
Bldg  190 

Wright  Patterson  Air  Force  Base,  OH  45433-6503 


NUMBER  OF  COPIES 


2 


2 


1 


1 


1 


1 


1 


1 


Distribution  List-1 


NAME  AND  ADDRESS 
Mr.  Pete  Everett 

South  Carolina  Research  Authority  (SCRA) 
Trident  Research  Center 
5300  International  Blvd 
North  Charleston,  SC  29418 

Ms.  Christine  Fisher 
Support  Systems  Technology 
Room  2B322 
The  Pentagon 
Washington,  DC  20301 

Mr.  Robert  Fletcher 

South  Carolina  Research  Authority  (SCRA) 
Trident  Research  Center 
5300  International  Blvd 
North  Charleston,  SC  29418 

Ms.  Nancy  Giddings 
Honeywell 
MN65-3420 
3660  Technology  Dr. 

Minneapolis,  MN  55418 

Mr.  Steve  Grout 
Martin  Marietta  Aerospace 
Liaison  Rep  CAD  Program 
3500  W.  Balcones  center  Dr. 
austin,  TX  78759 

Mr.  Don  Hall 
OASD  (P&L)/CALS 
Room  2B322 
The  Pentagon 
Washington,  DC  20301 

Dr.  Bob  Henderson 

South  Carolina  Research  Authority  (SCRA) 

PO  Box  12025 
Columbia,  SC  29211 

Dr.  John  Hines 
WRDC/ELED 
Bldg  620,  Area  B 

Wright  Patterson  Air  Force  Base,  OH  45433-6543 


NUMBER  OF  COPIES 
1 

1 

1 

1 

1 

1 

1 

1 


Distribution  List-2 


NAME  AND  ADDRESS 
Mr.  John  Hodges 

South  Carolina  Research  Authority  (SCRA) 
Trident  Research  Center 
5300  International  Blvd 
North  Charleston,  SC  29418 

Dr.  Raj  Kant 
Honeywell 

Systems  and  Research  Center 
3600  Technology  Dr. 

Minneapolis,  MN  55418 

Mr.  Robert  Kiggans 

South  Carolina  Research  Authority  (SCRA) 
Trident  Research  Center 
5300  International  Blvd 
North  Charleston,  SC  29418 

Dr.  John  F.  Kramer 
DARPA 
1400  Wilson  Blvd 
Arlington,  VA  22209-2308 

Mr.  Jonathan  Krueger 

Honeywell 

MN65-2100 

3660  Technology  Dr. 

Minneapolis,  MN  55418 

Mr.  Thomas  Leedy 
NIST 

Bldg  220,  Office  B-162 
Gaithersburg,  MD  20899 

Mr.  Dan  Lewallin 
WRDC/MTC 

Wright  Patterson  Air  Force  Base,  OH  45433-6533 

LtCol  Charles  Lillie 
SDIO/ENA 
Room  1E149 
The  Pentagon 

Washington,  DC  20301-7100 


NUMBER  OF  COPIES 
1 

1 

1 

1 

1 

3 

1 

1 


Distribution  List-3 


NAME  AND  ADDRESS 

Dr.  Michael  McGrath 
OASD  (P&I ) 

Room  2B322 
The  Pentagon 
Washington,  DC  20301 

Capt.  Nicholas  Naclerio 
DARPA,  DMO 
1400  Wilson  Blvd 
Arlington,  VA  22209 

Mr.  Larry  O’Connell 
SANDIA  National  Laboratory 
Division  2812  CAE  Integration 
PO  Box  5800 
Albuquerque,  NM  87185 

Mr.  Curt  Parks 
NIST 

Bldg  220,  Room  B-162 
Gaitherburg,  MD  20899 

Dr.  Jay  Patel 
Honeywell 

Systems  and  Research  Center 
2600  Ridgway  Parkway 
PO  Box  312 

Minneapolis,  MN  55440 

Mr.  Barry  Perleman 

US  Army  Laboratory  Command 

ETDL 

ATTN  SLCET-MP 

Fort  Monmouth,  NJ  07703-5000 

Mr.  Bruce  Rasmussen 
WRDC/MTT 

Wright  Patterson  Air  Force  Base,  OH 
45433-6533 

Mr.  Randy  Reitmeyer 
US  Army  Laboratory  Command 
ATTN  SLCET 

Fort  Monmouth,  NJ  07703-5000 


NUMBER  OF  COPIES 
1 

1 

1 

1 

1 


1 

1 

1 


Distribution  I.ist-4 


NAME  AND  ADDRESS 

Mr.  William  Russell 
RADC/RBRP 

Microelectronics  Reliability  Branch 
Griffiss  Air  Force  Base,  NY  13441 

Mr.  Karl  H.  Shingler 
Department  of  the  Air  Force 
Software  Engineering  Institute 
Joint  Program  Office  (ESD) 

Carnegie  Mellon  University 
Pittsburgh,  PA  15213-3890 

Mr.  Bruce  Speyer 
Microelectronics  and  Computer 
Technology  Corporation 
Computer  Aided  Design 
3500  West  Balcones  Center  Dr. 

Austin,  TX  78759 

Dr.  Jack  Stinson 
Citadel 

5300  International  Blvd 
North  Charleston,  SC  29418 

Mr.  Gregory  E.  Swietek 
Office  of  Space  Station 
NASA  Headquarters 
Strategy  Plans  and  Programs 
Code  ST 

600  Indpendence  Ave.  SW 
Washington,  DC  20546 

Maj.  John  Toole 
DARPA/ISTO 
1400  Wilson  Blvd 
Arlington,  VA  22209 

CSED  Review  Panel 

Dr.  Dan  Alpert,  Director 

Program  in  Science,  Technology  &  Society 

University  of  Illinois 

Room  201 

912-1/2  West  Illinois  Street 
Urbana,  Illinois  61801 


i 


NUMBER  OF  COPIES 
1 

1 


1 


1 

1 


1 


Distribution  List-5 


NAME  AND  ADDRESS 

Dr.  Thomas  C.  Brandt 
10302  Bluet  Terrace 
Upper  Marlboro,  MD  20772 

Dr.  Ruth  Davis 

The  Pymatuning  Group,  Inc. 

2000  N.  15th  Street,  Suite  707 
Arlington,  VA  22201 

Dr.  C.E.  Hutchinson,  Dean 
Thayer  School  of  Engineering 
Dartmouth  College 
Hanover,  NH  03755 

Mr.  A.J.  Jordano 
Manager,  Systems  &  Software 
Engineering  Headquarters 
IBM  Federal  Systems  Division 
6600  Rockledge  Dr. 

Bethesda,  MD  20817 

Dr.  Ernest  W.  Kent 
Philips  Laboratories 
345  Scarborogh  Road 
Briarcliff  Manor,  NY  10510 

Dr.  John  M.  Palms,  President 
Georgia  State  University 
University  Plaza 
Atlanta,  GA  30303 

Mr.  Keith  Uncapher 
University  of  Southern  California 
Olin  Hall 

330A  University  Park 
Los  Angeles,  CA  90089-1454 

IDA 

General  W.Y.  Smith,  HQ 
Mr.  Philip  L.  Major,  HQ 
Dr.  Robert  E.  Roberts,  HQ 
Mr.  John  Boone,  CSED 
Mr.  Herbert  R.  Brown,  CSED 
Ms.  Anne  Douville,  CSED 
Dr.  Dennis  W.  Fife,  CSED 
Mr.  Terry  Mayfield,  CSED 


NUMBER  OF  COPIES 
1 


1 


1 


1 


1 


1 


1 


1 

1 

1 

1 

1 

1 

1 

1 


Distribution  List-6 


NAME  AND  ADDRESS 


NUMBER  OF  COPIES 


Ms.  Katydean  Price,  CSED  2 

Dr.  Larry  H.  Reeker,  CSED  1 

Dr.  Robert  M.  Rolfe,  CSED  30 

Mr.  Edgar  H.  Sibley,  CSED  1 

Dr.  Richard  Wexelblat,  CSED  1 

IDA  Control  &  Distribution  Vault  3 


Distribution  List-7 


